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Abstract. We define and explore the concept of ideal stabilization. The program 
is ideally stabilizing if its every state is legitimate. Ideal stabilization allows the 
specification designer to prescribe with arbitrary degree of precision not only the 
fault-free program behavior but also its recovery operation. Specifications may 
or may not mention all possible states. We identify approaches to designing ideal 
stabilization to both kinds of specifications. For the first kind, we state the nec- 
essary condition for an ideally stabilizing solution. On the basis of this condition 
we prove that there is no ideally stabilizing solution to the leader election prob- 
lem. We illustrate the utility of the concept by providing examples of well-known 
programs and proving them ideally stabilizing. Specifically, we prove ideal sta- 
bilization of the conflict manager, the alternator, the propagation of information 
with feedback and the alternating bit protocol. 



1 Introduction 

A program is self-stabilizing [8, 9, 20] (or just stabilizing) if, regardless of the 
initial state, it eventually satisfies its specification. This elegant property enables 
the program to recover from transient faults or lack of initialization. During 
this stabilization period the program behavior is unpredictable. It is tempting 
to attempt to engineer the specification such that the program behavior during 
fault-recovery is controlled. For example, the program starts behaving correctly 
in no more than ten steps, or critical messages are never lost. However, one of 
the features of classic stabilization is that the program does not have to satisfy 
the specification for an arbitrary amount of time. That is, the program is free to 
ignore the recovery constrains built into the specification. 

Another disadvantage of stabilizing programs is their poor compositional 
properties. Stabilization programs are usually composed by layers: an lower 
level components are not influenced by the higher level components and, after 
the lower component starts behaving correctly, they higher level, due to stabi- 
lization will eventually behave correctly as well. However, if there is non-trivial 
two-way interaction between components, the stabilization or correct operation 
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of the composed system is not guaranteed. These shortcomings diminish the 
attractiveness of stabilization as a viable fault-tolerance technique. 

In this paper we study the class of programs that always satisfy their speci- 
fication. We call such programs ideally stabilizing. Related concepts are period- 
ically considered by fault-tolerance researchers. However, these approaches are 
often regarded as theoretical curiosity with a few isolated examples of no practi- 
cal importance. Our thesis is that the opposite is true. Ideal stabilization retains 
most of the advantages of classical stabilization while allowing the engineers 
and program designers to control the program behavior during fault recovery. 
Moreover, since the ideally stabilizing programs always satisfy their specifica- 
tion, their composition is similar to conventional program composition. Thus, 
the vast array of established program composition techniques can be applied to 
ideally stabilizing programs. We are thus hopeful that our approach to stabi- 
lization makes the general concept of self-stabilization more attractive to fault- 
tolerance practitioners. 

Related work. Ideal stabilization is close to snap-stabilization [3, 6] and should 
be considered complementary. However, snap-stabilization is defined in terms 
of immediate correct satisfaction of external invocations. Such definition may 
lead to specifications with sequence-based safety and liveness properties. Prov- 
ing stabilization to such specifications often results in operational proofs that 
are difficult to verify. Ideal stabilization, on the other hand, does not restrict 
specifications in any way. 

Adding safety properties to self-stabilizing protocols has been a very active 
recent path of research, however most approaches make some restrictions on the 
nature or the extent of the faults in order to guarantee a particular kind of safety. 
Safe stabilization [12,2] refers to the fact that/ew faults hitting the network 
should not compromise a particular safety predicate, while preserving global 
self-stabilization of the system. Also, the line of work about fault-containing 
stabilization [13] may handle only a single transient failure to ensure actual 
containment and recovery, and super-stabilizing protocols [10] can withstand 
one topology change at a time. When faults are simple enough to be detected by 
checksums [16], it is also possible to maintain elaborate safety predicates. Other 
approaches included using external entities that enforce safety [11] or make use 
of non-corruptible memory [18]. By contrast, ideal stabilization does not restrict 
the nature or the extent of the transient faults that can hit the system in any way, 
and does not make use of any external entity. 

Our contribution. In this paper we study two approaches to ideal stabilization. 
The approaches depend on the specification type. Specification itself is ideal if 
it allows (i.e. mentions) all possible states. Specification is not ideal otherwise. 



Ideal stabilization to specifications that are not ideal hinges on the approach we 
call state displacement. The specification implementer provides such mapping 
from program states to specification states that none of the possible program 
states map to disallowed specification states. We identify the necessary con- 
dition for such specifications to allow ideal stabilization and explain how two 
well-known programs: conflict manager and the alternator use state displace- 
ment to achieve ideal stabilization. 

The second approach relies on stating the specification such that all the pos- 
sible states are allowed. This allows the engineer to specify precisely what be- 
havior, including failure recovery behavior, is expected of the program. Ideally 
stabilizing program, by definition, has to follow this specification exactly. We 
state a proposition that states that such programs are rather common. As an ex- 
ample, we consider the problem specifications for two well-known stabilizing 
programs: propagation of information with feedback and alternating -bit proto- 
col and provide assertional proofs that the programs ideally stabilize to these 
specifications. 

2 Model 

This section introduces the notation and terms we use in the rest of the paper. 
To the person familiar with the literature on self-stabilization, our notation may 
look fairly conventional. However, we encourage even the specialists to read 
this section as the understanding of the results in the further sections hinges on 
the notions defined in this one. 

Program. A program consists of a set of N processes. Each process contains a 
set of variables. Every variable ranges over a fixed domain of values. Variable 
v of process p is denoted v. p. A process state is an assignment of a value from 
its domain to each variable of the process. A program state, in turn, is an as- 
signment of a value to every variable of each process. The Cartesian product of 
the values of all program variables is program state universe. That is, the state 
universe defines all states that the program can assume. 

Each process also contains a set of actions. An action has the form (name) : 
(guard) — ► (command). A guard is a predicate over the variables of the 
process. A command is a sequence of assignment and branching statements. 

An action whose guard is true at some program state is enabled in that state. 
The execution of an enabled action changes the values of program variables and 
thus transitions the program from one state to another. A program computation 
is a maximal sequence of such transitions. By maximality we mean that the 
computation is either infinite or it ends in a state where none of the actions are 



enabled. Note that we do not assume any fairness of action execution for infinite 
computations. 

Communication model, extended state. Processes that share variables are neigh- 
bors. The communication model determines the type and access method of the 
variables shared by neighbor processes. For example, in shared-memory com- 
munication model, the process may mention the variables of the neighbor pro- 
cesses in its actions. That is, the process may read the state of its neighbor 
processes. The extended state of the process is the state of its local variables and 
the variables that the process can read. 

Problem specifications and program sequence mapping. Problem specifica- 
tion prescribes the program behavior. This is done by defining the program in- 
puts and outputs through external variables. External variables are thus either 
input or output variables. Input variables are modified by the environment while 
the program may only read them. The output variables are updated by the pro- 
gram, they are used to display the results of the program computation. 

The problem specification is the set of sequences of states of external vari- 
ables. A program implements the specification. Part of the implementation is the 
mapping from the program states to the specification states. This mapping does 
not have to be one-to-one. However, we only consider unambiguous programs 
where each program state maps to only one specification state. 

We make another important assumption about program sequence mappings. 
The mappings have to be merge- symmetric. Specifically, let there be a set of 
program states pr\ through pr^ such that they map to specification states s\ 
through Sfe. Then, if there is a specification state s m such that the extended 
state of each process p in s m is the same as in one of the states s\ through 
Sk, then there exists a program state pr m that maps to s m . In other words, any 
specification state formed by extended process state-preserving combination of 
other specification states, has a program state that maps to this new specification 
state. Most known mappings are merge-symmetric. 

Identical mapping maps every program state to the specification state. That 
is, the program operates external variables only. Another simple program map- 
ping is projection. Each process maintains output variables and internal vari- 
ables for computations and record keeping. The projection of program states 
onto specification states removes the internal variables. However, the mapping 
may not be as straightforward as identical mapping or projection. For example, 
the specification requires the output variable of a process be boolean while the 
program maintains an integer variable. The mapping is such that the even values 
of the integer variable are mapped to true while odd values to false. 



Once the mapping between program and specification states is established, 
the program computations are mapped to specification sequences as follows. 
Each program state is mapped to the corresponding specification state. Then, 
stuttering, the consequent identical specification states, is eliminated. 

The program does not have to implement all specification sequences. How- 
ever, the program cannot select implementation sequences so that it ignores en- 
vironment input. Hence the following notion of input completeness. Given a set 
of sequences A, a subset B C A is input-complete if, for every sequence a € A, 
there exists a sequence (3 € B such that: every step s\ of a is also in [3 and for 
every pair of steps s\ and S2 their order in a and (3 is the same. Informally, the 
sequences in an input-complete subset B preserve the results and the order of 
the input steps in A. 

The state universe of the specification is the Cartesian product of the values 
of all the external variables. The state that is present in one of the specification 
sequences is allowed by the specification. The state is disallowed otherwise. 
The specification is ideal if it allows every state in its state universe; otherwise 
the specification is not ideal. 

We only consider specifications that are suffix-closed. That is, every suffix 
of a specification sequence is also a sequence in this specification. Suffix closure 
enables us to discuss the correctness of the program on the basis of its current 
state rather than potentially arbitrary long program history. This facilitates as- 
sertional reasoning about program correctness. 

Predicates, invariants, stabilization. A state predicate is a boolean expression 
over program variables. A program state conforms to predicate R, if R evaluates 
to true in this state; otherwise, the state violates R. By this definition every state 
in the program state universe conforms to predicate true and none conforms to 
false. 

The predicate defines a set of program states that conform to it. In the sequel 
we use the predicate and the set of states it defines interchangeably. Predicate 
R is closed in a certain program V, if every state of every computation of V 
conforms to R provided that the computation starts in a state conforming to R. 

A closed predicate / is an invariant of the program V with respect to spec- 
ification S if I has the following property: every computation of V that starts 
in a state conforming to /, maps to a sequence that belongs to the specifica- 
tion. A program state is legitimate if it conforms to the invariant and illegitimate 
otherwise. 

Program V satisfies (or solves) specification S, if there exists an invariant / 
of V with respect to S such that the mappings of the program computations that 
start from / form an input-complete subset of S. That is, the program does not 



have to implement all the specification sequences, but it does need to accommo- 
date all possible inputs. Specifically, it needs to implement an input-complete 
subset of these sequences. 

A program V is stabilizing to specification S if every computation that starts 
in an arbitrary state of the program sate universe contains a state conforming 
to the invariant with respect to S. Therefore, any computation of a stabilizing 
program contains a suffix that implements a specification sequence. 

Definition 1. A program is ideally stabilizing if every state in its state universe 
is legitimate. 

That is, true is an invariant of an ideally stabilizing program. 

3 State Displacement 

3.1 Necessary Condition for Specification 

A non-ideal specification disallows certain states in its state universe. Yet, every 
state in the program state universe is legitimate. Thus, for a program to ide- 
ally stabilize to such specification, the state mapping should be such that the 
disallowed states are displaced. That is, none of the states in the program state 
universe maps to the disallowed states. However, state displacements may not 
be possible for an arbitrary specification. In this section we provide a theorem 
that establishes a necessary condition for a specification to be solvable by an 
ideally-stabilizing program. 

Theorem 1. An ideal stabilization is possible to non-ideal specification only if 
the specification contains an input-complete subset of sequences such that in 
every disallowed specification state there is at least one process whose extended 
state does not occur in any of the specification states of this subset. 

Proof: Assume the opposite. There is, a non-ideal specification S that disal- 
lows state d and for every input-complete subset C of S and for every process 
Pi, where i = 1, N, there is a specification state Cj in one of the sequences of C 
such that the extended state of pt is the same in Cj and in d. However, there is a 
program V that ideally stabilizes to S. 

Since V solves S, V implements an input complete-subset of S. Assume, 
without loss of generality, that V implements C. That is, for every sequence of 
C there is a computation of V that maps to this sequence. This means that for 
each specification state of C, there is a program state of V that maps to it. This 
includes the states q. For each i, let pvi be the program state of V that maps to 

a. 



Recall that the extended state of each process in d is the same as in one of 
the states q. If this is the case then, according to merge-symmetry of program 
mapping, there exists are program state pr^ that maps to d. Let us consider the 
computation of V that starts in pr^. This computation contains a state that maps 
to a disallowed state, pr^ itself. That is, this computation maps to a sequence 
outside the specification S. This means that d does not conform to an invariant 
of V with respect to S. That is, pr^ is an illegitimate state. However, if V has 
an illegitimate state then, contrary to our initial assumption, V does not ideally 
stabilize to S. Hence the theorem. □ 



3.2 Examples 

To illustrate the concept of ideal stabilization to non-ideal specifications and the 
ramifications of Theorem 1, we provide several examples. 

Conflict manager. The specification we consider is a simplified (unfair) variant 
of the dining philosophers problem [4, 7] that we call UW. The program is 
adapted from the deterministic conflict manager presented by Gradinariu and 
Tixeuil [15]. The processes are arranged in a chain. Every process has a unique 
identifier. The specification defines one external output boolean variable in per 
process. If the value of in is true, the process may execute the exclusive critical 
section of code. The specification defines infinite sequences where in variables 
alternate between true and false. The sequences are not necessarily fair as a 
certain process may never be given a chance to execute the crucial section. That 
is, an input-complete subset of the specification contains any subset of such 
sequences. 

The specification prohibits concurrent critical section access by neighbor 
processes. That is, the specification disallows states where in variables of two 
neighbors are true in the same state. Assuming shared memory communication, 
the extended state of the process contains the state of its neighbors. Hence, none 
of the allowed specification states contain an extended process state where both 
the process and one of its neighbors are inside the critical section. The specifi- 
cation thus satisfies the conditions of Theorem 1. 

The conflict manager program CM. is as follows. Each process has a sin- 
gle boolean variable access and a single action flip that is always enabled. The 
action toggles the value of access. 



flip : true — ► access := ^access 



The program mapping is this. For each process p the variable p.in is true 
if p.access is true and p has the highest identifier among its neighbors with 
access set to true. 

Let us discuss why this mapping is merge-symmetric. Any extended pro- 
cess state-preserving combination of specification states produces a specifica- 
tion state where neighbors are not accessing the critical section. Then, by appro- 
priately setting access variables, we can generate the program state that maps 
to this specification state. 

Let us give an illustration for this reasoning. Assume we have a chain of 
four processes with identifiers (2, 1, 3, 4). The extended state of each process in 
this case is its own state plus the state of its left and right neighbors. Consider 
two specification states 

si = (true, false, false, false) 

and 

S2 = (false, false, false, true) 

Some of the program states that map to s\ and S2 are respectively pr\ = 
(true, true, false, false) andpr2 = (false, false, false, true). 

Specification state S3 = (true, false, false, true) is formed by merging states 
si and S2- Note that the extended states of each process in S3 are the same in ei- 
ther si or S2- For example, the extended state of process P2 is (true, false, false), 
which is the same in si and S3. Note that there are a number of program states 
that map to S3. For example, pr% = (true, false, false, true). 

Theorem 2. Program CM ideally stabilizes to the unfair dining philosophers 
specification UT>V. 

Proof: To prove ideal stabilization we need to show that a computation of 
CM from an arbitrary program state satisfies UT>V. First, we show that every 
state of CM maps to an allowed state of UW '. Indeed, among the neighbors 
whose access is true, in is set to true only for the process with the highest iden- 
tifier. That is, every program state maps to the state of UW where neighbors 
do not access the critical section concurrently. Hence, no program state maps to 
a disallowed state. 

Moreover in every computation of the program at least one process, the pro- 
cess with the largest identifier in the system, alternates between setting access 
to true and false. This means that this process alternates between entering and 
exiting the CS indefinitely. Such computations satisfy the specification. That is, 
CM ideally stabilizes to UW. □ 



Leader election. We show a simplified leader election problem CS as an exam- 
ple of the specification to which ideally stabilizing solutions do not exist. Again, 
the processes form a chain. In this case, we only consider N > 3. In the exter- 
nal state, each process has two boolean variables: an input variable contend and 
an output variable leader. The value of the input variable contend is set to a 
particular value and does not change throughout the specification sequence. In 
each specification state leader of at most one process is true. To exclude trivial 
solutions, the specification requires that the leader is elected only out of the pro- 
cesses that contend for leadership. That is, the processes whose contend vari- 
able is true. Each specification sequence is finite and ends with a state where 
the leader is elected. Note that the input complete subset of sequences has to 
contain a sequence for every combination of the contending processes. 

Theorem 3. There does not exist a program that ideally stabilizes to the sim- 
plified leader election specification CS. 

Proof: Let us consider state s\ where the first process is the only one con- 
tending for leadership. This is the process that has to be elected leader. That 
is, the following output state has to be in every input-complete subset. s\ = 
(true, false, • • • , false, false) Similarly, let S2 be the state where the last pro- 
cess is the only one contending: S2 = (false, false, • • • , false, true). 

We now form the state S3 where both the first and the forth processes are 
contending for leadership and both of them are elected. That is, 

s 3 = (true, false, • • , false, true) 

This state is disallowed . Yet, the extended state of every process is present in 
either s\ or S2. Thus, according to Theorem 1, ideal stabilization is not possible 
to CS. □ 



Linear alternator. For another example, we demonstrate how a well-known 
program called the linear alternator CA proposed by Gouda and Haddix [14] 
fits into our ideal stabilization model. The alternator provides a solution to the 
fair variant of the dining philosophers problem TT>V. The problem specification 
is the same as described above except all the sequences are fair with respect to 
the process critical section access. The modified specification still excludes the 
states where two neighbors are executing the critical section concurrently and 
the specification still satisfies the conditions of Theorem 1 . Therefore, the ideal 
solution is still possible for this specification. 



The implementation of CA is as follows. Similar to CM. manager, each 
process has a boolean variable x. This time though we assume that the processes 
in the chain are numbered in the increasing order from 1 to N. The numbering 
is for presentation purposes only as as each process only need to be aware of 
its right and left neighbor. The process actions are as follows. In the actions, 
parameter j ranges from 2 to N — 1. 

x.pi = x.p2 — ► x.pi : = -ix.pi 
(x.pj / z.pj-i) A (x.pj = x.p j+1 ) — ► x.pj := ^x.pj 

X-PN-l / X.p N > X.p N := ^X.p N 

The program to specification states mapping is as follows. For each process 
Pj, the output variable in.pj evaluates to true if process' action is enabled. 

Theorem 4. Program CA ideally stabilizes to the fair dining philosophers spec- 
ification TT>V. 

Proof: 

Gouda and Haddix [14] prove that the alternator satisfies the fairness prop- 
erties of the dining philosophers specification from an arbitrary program state. 
We only show the displacement of disallowed states. Note that an action of a 
process p is enabled if x.p is not equal to the left neighbor's variable and equal 
to the right neighbor's variable. This can only hold for one process in the neigh- 
borhood. That is, every program state maps to a specification state where none 
of the neighbors are in the critical sections concurrently. In other words, the 
program states only map to the allowed states. Hence the theorem. □ 

4 Stabilizing to Ideal Specifications 
4.1 Forming Ideal Specifications 

Another method of achieving ideal stabilization is by stating the specification 
such that all the states in its universe are legitimate. That is, stating ideal spec- 
ification. At first sight this seems difficult to achieve. However, the following 
proposition demonstrates that such specifications are rather common. 

Proposition 1. For every program there is an ideal specification to which this 
program ideally stabilizes. 

We provide an informal argument for the validity of this proposition. Con- 
sider any program and all the computations produced by this program when it 
starts from an arbitrary state of its universe. Now define the specification that 
contains exactly these computations. This specification is ideal as all the states 



of its state universe are allowed while the program ideally stabilizes to this spec- 
ification. 

Naturally, this kind of specification may not be very useful as it, in essence, 
defines specification to be whatever the program computes. However, below we 
describe how a number of stabilizing program published in the literature can be 
defined as ideally stabilizing to ideal specifications. 

4.2 Examples 

Propagation of Information with Feedback. As the first example we describe 
a program VTT that ideally stabilizes to the propagation of information with 
feedback [5, 19] specification. The presentation of this program as snap-stabilizing 
is well-known [3]. The program is presented on rooted trees. However, to sim- 
plify the presentation, we describe the operation of this program on a chain. 

For ease of exposition we preserve the rooted tree terminology. Similarly to 
the alternator, we assume that the processes are numbered from 1 to N from 
left to right in the chain. We refer to the leftmost processor, with identifier 1, as 
root; the rightmost, with identifier N, as leaf; and the processes in between as 
intermediate. For each process p, the processes to the left of it are ancestors and 
to the right — descendants. 

Each process has a state variable st. In the intermediate processes, the vari- 
able may hold one of the three values: i, rq, rp which stand for idle, requesting 
and replying respectively. The root can only be idle or requesting while the leaf 
can be either idle or replying. 

The objective of the program is to send a signal from the root to the leaf and 
in return receive an acknowledgment that matches this signal. Operationally, 
the program should ensure that after the root makes a request then every process 
propagates this request along the chain from left to right in causally ordered 
steps transitioning from idle to requesting. Afterwards, the processes propagate 
the reply from right to left in causally ordered steps transitioning from request- 
ing to replying. 

We define the following state predicates. RP(k) are the specification states 
where all k processes on the left are requesting (k = 1, N — 1) and the rest 
of the processes are replying. RQ(l, m) are the specification states where all I 
processes on the left are requesting (/ = 0, N — 1) and all m — I processes 
following them are idle (m = I + 1,N) while the remaining processes are 
replying. Specification SVTT includes the sequences where the system satisfies 
one of the predicates and transitions from one to the other infinitely. 

Let us define another pair of predicates. Predicate RP'(k) defines the states 
where k processes on the left are requesting (k = 1, N — 1), the process k + 1 



is replying and none of the rest are idle. Notice that RP{k) C RP'(k). Pred- 
icate RQ'(l,m) are the states where all I processes on the left are requesting 
(I = 0, N — 1), all m — 1 following them are idle (m = I + 1, N) and the state 
of the other processes is arbitrary. Similarly, RQ(l,m) C RQ'(l,m). Specifi- 
cation TVTT includes the sequences where the system always satisfies either 
RP'(k) or RQ'(l, m), each sequence has a sequence in SVTT as a suffix and 
the transition from RQ'(l, m) is only to RP{k). 

We now describe program VTT. It has only external variables. The map- 
ping between the program and specification variables is identical. The actions 
of VTT are shown in Figure 1 . 



request : 
clear : 

forward : st.pj-i = rq 

back : st.pj-i = rq 

stop : st.pj-i = i 

reflect : st.pN-i = rq 

reset : st.pN-i = i 



st.pi — i A st.p2 = 

st.pi = rq A st.p 2 = 

A st.pj = i A st.pj+i 

A st.pj = rq A st.pj+i 

A st.pj i 

A st.pN = i 

A st.pN = rp 



i — > st.pi := rq 
rp — > st.pi := i 
= i — " st.pj := rq 
= rp — > st.pj := rp 

— > st.pN ■= rp 
— > st.pN := i 



Fig. 1. VTT program actions. Actions request and clear belong to the root process; actions for- 
ward, back, and stop - to intermediate processes, i.e parameter j ranges from 2 to N — 1; actions 
reflect and reset - to the leaf. 



Theorem 5. VTT classically stabilizes to SVTT and ideally stabilizes to TVTT. 

Proof: First, we prove that RQ(l, m) V RP(k) is an invariant of VTT with 
respect to SVTT. Notice that this disjunction is closed in VTT. That is, none of 
the actions of VTT violate the predicate. Let us show that a program transitions 
from RQ(l, m) to RP{k) and back. If the program satisfies RQ(l, m), at least 
one action is enabled. Indeed, if I = 0, m < N, request is enabled in stop is 
enabled in process p m +i .1f,l < m—l,m < N, request is enabled in pi + \. With 
the execution of an action either I or m are incremented. If I = N — l,m = N, 
reflect is enabled that transitions the program into RP(N — 1). Similarly, if the 
system satisfies RP(k) for k = 2, N — 1, action back is enabled. The execution 
of this action keeps the system in RP(k) but decrements k. If k = 1, clear 
is enabled. Its execution moves the program back in RQ(l,m). That is, the 
disjunction of the two predicates is closed and a VTT computation that starts in 
a state conforming to one of them, satisfies SVTT. Hence, RQ(l, m) V RP{k) 
is an invariant of SVTT. 

Observe that the disjunction of RQ'(l, m) V RP'{k) contains the program, 
as well as specification, state universe. We show that VTT stabilizes to SVTT 



from this predicate as required by XVTT. An argument similar to the above 
demonstrates that an action is enabled if VTT satisfies RP'(k). This action 
either decrements k or moves the system to RQ'(l, m). Also, similarly, if VTT 
satisfies RQ'(l,m), then an action is enabled that increments either I or m. 
Moreover, if I = N — 1, m — N, the execution of reflect transitions the system 
to RP(k). That is, VTT moves from RP'(k) to RQ'(l,m) to RP(k). This 
means that the program stabilizes to SVTT and ideally stabilizes to ZVTT. □ 

Alternating bit protocol. Alternating bit protocol is an elementary data-link 
network protocol. There is a number of classic stabilizing implementations of 
the protocol. Refer to Howell et al [17] for an extensive list of citations. There 
is also a snap-stabilizing version [6]. 

The problem is stated as follows. There are two processes: sender — p, and 
receiver — q. The processes maintain boolean sequence numbers ns.p and nr.q. 
The processes exchange messages over communication channels. The channels 
are reliable and their capacity is one. That is, if the channel is empty, the message 
is reliably sent. If the channel already contains a message, an attempt to send 
another message leads to the loss of the new message. The processes exchange 
two types of messages: data and ack. Both carry the sequence numbers. 

Specification SABV prescribes infinite sequences of states where there is 
exactly one message in the channels. The message carries the sequence number 
of the sender. The state transitions are such that p changes the value of ns. This 
change is followed by the change of the value in nr that matches the value of 
ns. 

Specification of TABV is such that for every state in the universe there is a 
sequence that starts in it and every sequence contains a sequence of SABV as a 
suffix. Specification of TABV is thus ideal. 

The program ABV uses only external variables as described by SABV and 
TABV. ABV actions are shown in Figure 2. The sender has two actions: next 
and timeout. Action next is enabled if there is a message from q in the channel. 
The timeout action is enabled if there are no messages in either channel. Upon 
receiving a message from q with matching sequence number, p increments the 
sequence number and sends the next message. If p times out, it resubmits the 
same message. The receiver has a single action. When q, receives a message, 
it sends an acknowledgment back to p. If the message bears a sequence num- 
ber different from rn, q increments rn signifying the successful receipt of the 
message. 

Theorem 6. ABV classically stabilizes to SABV and ideally stabilizes to TABV. 



ns=nr next ns*nr 




Fig. 2. ABV actions. Fig. 3. ABV state transitions. 

Proof: We prove the correctness of the theorem by enumerating the state 
transitions of VTT . We classify the state universe of ABV into two groups: 
(i) ns is equal to nr and (ii) ns is not equal to nr. The states are further clas- 
sified according to the type of messages in the channels. The states and state 
transitions are shown in Figure 3. Note that to simplify the diagram we do not 
show the states that contain more than a single message. However, after a single 
transition, the program moves from one of those states to a state shown in the 
figure. The correctness of the theorem claims can be ascertained by examining 
the states and transitions shown in the figure. □ 

5 The Impact of Ideal Stabilization Approach 

In this paper we proposed a new way of approaching stabilization. Our approach 
eliminates two of the most problematic features of classic stabilization: unpre- 
dictable behavior during stabilization and poor composability. We hope that this 
work adds more credence to stabilization as a viable fault-tolerance technique 
and generates more interest in the subject among both theoretical researches and 
reliability engineers. 
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